Miskolci SZC Kandó Kálmán Informatikai Technikum
Szoftvertesztelés - 1/13.C 2. csoport
1. BevezetésMi a szoftvertesztelés?A szoftvertesztelés a szoftverfejlesztési folyamat önálló része, ami szorosan kíséri a fejlesztés folyamatát. A szoftvertesztelés egy rendszer vagy egy program kontrollált körülmények melletti futtatása, és az eredmények kiértékelése. Feladatai közé tartozik a fejlesztők és a döntéshozók tájékoztatása, a fejlesztés állapotának mérése és a kockázatkezelés/kockázatbecslés. A szoftvertesztelés a szoftver jellemző tulajdonságait vizsgálja, minőségbiztosítási tevékenység. Felhasználói szemszögből:"Mennyire alkalmas a felhasználó céljára? " Tesztelői szemszögből: „Mennyire egyezik a specifikációval?” A szoftverek tesztelését megtervező, végrehajtó és az eredményeket kiértékelő szakember a szoftvertesztelő, vagy tesztmérnök. A tesztelés, célja, emberi vonatkozásai, anyagi előnyeiA szoftverfejlesztés célja a tesztelt szoftver minőségének értékelése és jobbítása, a hibák korai felfedezése/megelőzése, és ezáltal a költségek csökkentése. A tesztelés elsődleges célja a hibák megtalálása és dokumentálása. Minél korábban derül fény egy hibára, annál olcsóbb annak korrigálása. Másik fontos cél a döntés-előkészítés támogatása: olyan információk előállítása, melyek alapján kijelentéseket lehet megfogalmazni a szoftver minőségéről, és döntéseket lehet hozni. Elvárás/cél lehet még a szoftverminőség mérése. A minőség az a mérték, amennyire a program, a része vagy egy folyamat megfelel a követelményeknek. A tesztelés a kockázatok becslését és menedzselését is magába foglalhatja (főleg az Agile Programming esetén). A tesztelés emberi vonatkozásai:2. A tesztelés alapfogalmaiA hiba fogalmaHibázás (error, mistake): hibajelenség létrehozásának, létrejöttének a folyamata. Hiba (defect, fault, bug): konkrét, kimutatható hibajelenség. Hibás működés (failure): a hibajelenségből eredő, az elvárttól eltérő működés, melyet nem emberi tényezők is okozhatnak (például, amikor áramszünet miatt leállnak szerverek) Debugging (hibakeresés, nyomkövetés): a szoftver felügyelt módban történő futtatása hibakeresés céljából a programozó által, a szoftver alkotóelemeinek ellenőrzésére. Ez nem minősül tesztelésnek. A debugging a fejlesztési munkafolyamat fontos része, mely a forráskód megírását és a futtatható szoftver létrehozását, valamint javítását segíti. TesztelésA szoftvertesztelés egy jól irányított, tervezett, dokumentált, ezáltal követhető és kiértékelhető folyamat, mely számadatokkal alátámasztva képes kijelentéseket megfogalmazni egy szoftver minőségéről. A tesztelés az tevékenység, melynek során - előre meghatározott feltételek teljesülése esetén - a teszt tárgyát képező szoftver adott tulajdonságát előre meghatározott ismérvek és feltételrendszerek alapján megvizsgáljuk, elemezzük, dokumentáljuk és összefoglaljuk. A teszttevékenység végrehajtását tesztvégrehajtásnak, tesztfuttatásnak (test run) nevezzük. TesztkörnyezetA tesztkörnyezet egy olyan informatikai infrastruktúra, mely a leendő, vagy már meglévő éles rendszerinfrastruktúrát modellezi, ill. a felhasználás körülményeit szimulálja. Tesztkörnyezet állhat egyetlen számítógépből, de akár több kontinensen szétszórt, hatalmas számítógépközpontokból is. Ideális esetben a tesztkörnyezet tulajdonságai megegyeznek az éles környezetével. A költségek kímélése végett a valóságban az éles rendszer paramétereihez közeli tesztkörnyezeteket szoktak létrehozni. Éles rendszert tesztelésre használni tilos! Üzleti követelményAz üzleti követelmény (business requirement) üzleti folyamatok leírása, a megrendelő üzleti igényei alapján (pl. banki szoftver esetében ügyfél hitelkérelmének elfogadása). Felhasználási folyamatleírások (user story)Ezen leírások részletessége változó, de gyakran hasonlóak a tesztesetek tesztlépéseinek leírásához (lásd lentebb). Megfogalmaznak feltételeket, tevékenységeket és ún. elvárt eredményeket. Teszt forgatókönyvA teszt forgatókönyv (test scenario) az üzleti követelményekből levezetett összefoglaló leírás. A teszt szcenárió, felhasználási eset és üzleti követelmény a gyakorlatban nem feltétlenül különálló leírásokat jelent. Erre egységesen alkalmazott rendszer a gyakorlatban nincsen, projektenként változhat a megvalósításuk. TesztesetA teszteset (test case) a tesztvégrehajtás során elvégzendő, logikailag összetartozó teszttevékenység. A teszteseteket különböző névkonvenciók alapján nevekkel szokás ellátni, melyek utalnak a teszt tárgyára. Például: Test_#1_Új_ügyfél_felvétele TesztlépésA tesztlépés (test step): a teszteset egyes elemi tevékenysége, további lépésekre nem bontható. Ezáltal a hiba visszakereséséhez, javításához elegendő egyetlen lépést megvizsgálni. A tesztlépés két legfontosabb szerkezeti egysége:
ReviewReview (felülvizsgálat): az elkészített tesztesetet egy másik tesztelő leellenőrzi, hogy valóban megfelel-e minden követelménynek és minden szükséges információt tartalmaz-e. A módszer hatékonyan alkalmazható hasonló és eltérő tapasztalattal rendelkező tesztelőknél is. A gyakorlati kivitelezése lehet informális, de akár erősen formalizált, írásban rögzített is. A felülvizsgálat végén a teszteset eredeti készítője megkapja mindazon hiányosságok listáját, melyeket még be kell építenie a tesztesetbe. Egy teszteset elviekben csak review után használható éles tesztelésre. Teszt státuszA tesztek státusza egy fogalom, elnevezés, mely röviden összefoglalja és megadja az adott tesztesethez tartozó teszt aktuális állapotát. Néhány példa tesztek státuszaira:
A státuszok sorrendjét ajánlatos előre meghatározni is, ez segíthet nagyszámú hibajelentés feldolgozásában. Folyamatábrával áttekinthető, hogy egyik státusz után milyen másik következik. Példa: 
Tesztlépések megfogalmazása
Negatív tesztesetekA negatív tesztesetek a hibatűrés ellenőrzésére irányul, cél a hibajelenség elérése (pl. biztonsági teszteknél) Tesztelés fázisai
A tesztek megtervezéseA tesztek végrehajtását gondos tervezés előzi meg. A tervezés során meghatározzák a teszt célját, a teszt tárgyát, a teszttevékenységek végrehajtásának feltételeit, módját és a kiértékelés kritériumait. A tervezést a tesztmenedzser, vagy a vezető tesztelő készít el. A tesztterv nem részletes technikai megvalósításokat taglal, hanem folyamatokat ír le, témaköröket mutat be. A fejlesztők megtudhatják belőle, hogyan és mire alapozva fognak hibajelentéseket kapni a tesztelőktől, a megrendelő pedig megbizonyosodhat afelől, hogy a szoftvert minden, általa fontosnak ítélt szempont szerint le fogják tesztelni. A tesztterv módosítható a résztvevők javaslatai alapján. Fontos, hogy a teszttervben vegyük figyelembe a fejlesztőknek észrevételeit, módosító javaslatait. Teszt tervezés sprintekbenTesztek tervezésére nemcsak projektek induló fázisában, hanem sprintekben (SCRUM rendszerben) is szükség van. Ez egy kevésbé formalizált tervezés, inkább egy kötetlen szakmai beszélgetés például az üzleti elemző, a projekt menedzser, a fejlesztők és természetesen a tesztelők között. A tesztelők felelőssége, hogy ilyenkor minden kérdést tisztázzanak, amely a tesztelés végrehajtását veszélyeztetheti. Ennek során általában olyan kérdések is felmerülnek, melyek a fejlesztők számára is létfontosságúak, tehát az eljárással minden résztvevő jól jár. Ha ez a megbeszélés elmarad, az sprint közben többnyire megakasztja a tesztelés és nem ritkán a fejlesztés lendületét is. A tesztelők információk híján nem tudják pontosan ellátni feladatukat, menet közben kell tisztázni részleteket. Emiatt rengeteg idő elmehet, ami végeredményben többletköltséget eredményez. TesztelemzésA teszt végrehajtóinak a tesztterv céljai és végrehajtásának feltételei alapján tételesen meg kell vizsgálniuk, hogy a teszt kivitelezhető-e. Az elemzés során a teszt egyes részeinek a priorizálása is megtörténik. Fontos feltételek: tesztkörnyezet előkészítése, beszerzendő teszteszközök feltérképezése is. Tesztdizájn, előkészítésA tesztdizájn során a végrehajtandó tesztek tesztlépések szintjén vannak megfogalmazva. Ezek már nem magasszintű megfogalmazások, hanem konkrét tesztlépések szintjén leírt tevékenységek. Lényegében ekkor jönnek létre „fizikailag” is a tesztesetek. Fontos az esetlegesen szükséges tesztadatok meghatározása és előállítása, automatizált tesztek esetében a teszt szkriptek megírása, ill. az automatizálást segítő tesztelő szoftver beállítása. TesztvégrehajtásA tesztek végrehajtása (lefuttatása) során eredményt kapunk. Még az is eredmény, ha a teszt maga nem hajtható végre. A végrehajtás végén mindig a kiértékelés és az eredmények dokumentálása is megtörténik. TesztkiértékelésA kiértékelés során a dizájn fázisban megfogalmazott feltételek és a szintén akkor megfogalmazott, elvárt teszteredményeket hasonlítják össze a tényleges tesztvégrehajtás eredményeivel. A kiértékelésről egy rövid összegző jelentés készül, melyet teszt riportnak is neveznek. A tesztriport egyik változata a záró teszt riport (test exit report), mely a tesztelés egészét értékeli ki, annak teljes végrehajtása után és prezentálja a teszteredményeket is. Tesztelést támogató tevékenységekA tesztelés sikerességét befolyásoló fontos tényezők a tesztkörnyezet karbantartása és a tesztadatok előállítása. A tesztkörnyezet karbantartása egy kizárólag tesztelésre dedikált számítógép felügyeletét és folyamatos naprakészen tartását jelenti. A nem aktuális vagy hibás tesztadatok hibás teszteredményeket produkálnak, ami rengeteg időt vesz el (nyomozgatás) és plusz költségeket okoz. PriorizálásA Priorizálás egy fontossági sorrend meghatározása, ami alapján az egyes teszteket el kell végezni. Ennek egyik célja a hibák mihamarabbi felfedezése. 3. Tesztelési technikákStatikus tesztelésStatikus tesztelés esetén a tesztelők a rendelkezésre álló szoftverspecifikációk, tervek alapján már a tesztek végrehajtása előtt elkészítik a tesztjeik tervét, meghatározzák a tesztek elvárt eredményeit, felmérik, hogy a szoftver egyáltalán tesztelhető-e a tervezett módon, eszközökkel. A statikus tesztelés során a szoftver forráskódjának / dokumentációjának az ellenőrzésére kerül sor, különböző szempontok alapján. A fentiekből következik az is, hogy szigorúan véve ilyenkor nem hibákat, hanem potenciális hibaforrásokat keresünk. Ezeket a teszteket manuálisan és automatizáltan is végre lehethajtani. Automatizált ellenőrzésekre speciális forráskódelemző segédprogramok is használhatók. Dinamikus tesztelésDinamikus tesztelés a szoftverek futtatásán alapuló tesztelés, amikor a szoftver tesztkörnyezteben fut. Nemcsak a fejlesztési fázisban, hanem annak teljes életciklusán keresztül alkalmazható. Fekete doboz tesztelésA tesztelő nem rendelkezik információval a szoftver belső struktúrájáról. Ez a tesztelés hasonlít leginkább a végfelhasználói viselkedésre. Néhány példa:
Fehér doboz tesztelésA tesztelőnek pontosan ismernie kell a szoftver belső szerkezetét, működését és ehhez szabva tervezi meg és hajtja végre a teszteket. A fehér doboz teszteket szokás strukturális teszteknek is nevezni. Néhány példa:
Szürke doboz tesztelésA tesztelő korlátozott ismeretekkel rendelkezik a tesztelendő szoftver belső szerkezetéről is, de ez lehet technikai adat is, például a szoftver által kezelt adatstruktúrákról. Felfedezéses tesztelésA tesztelő a teszt során ismeri meg a szoftvert úgy, mint egy kezdő felhasználó. A módszer előnye, hogy nem rögzített munkafolyamatok mentén zajlik a tesztelés, hanem műveletek véletlenszerű kombinációjával. Így olyan rejtett hibákat is lehet találni, melyek csak sokkal később derülnének ki, a felhasználói oldalon. Tesztvégrehajtás fajtái:Manuális tesztelésA tesztelő számítógépnél teszteseteket hajt végre, az azokban megfogalmazott lépéseket követve. A manuális tesztelés óriási előnye a rugalmasság, hiszen bármely pontján módosítani lehet a teszt végrehajtását. Ráadásul az emberi intuíció is teljes mértékben kiaknázható, amire egy gép nem képes. Hátránya a magas költsége, illetve az, hogy nagy mennyiségű, vagy komplexitású tesztekre nem alkalmazható. Automata tesztelésAz automatizált tesztek emberi beavatkozás nélkül hajtódnak végre. Technikai hátterük változatos: szkriptek, programozási nyelvek, speciális segédprogramok. Az automata tesztek gyorsan, nagy mennyiségű tesztet és tesztadatot képesek kezelni, így olyan feladatokra is alkalmasak, melyekre a manuális tesztek nem. Hátrányuk, hogy speciális technikai ismereteket igényelnek és a karbantartásuk is időigényesebb. 4. Tesztek osztályozásaFejlesztési modellek:V-modellA V-modell egyfajta lineáris fejlesztési folyamat, melynek főbb állomásai:
Agilis fejlesztésA fejlesztésben résztvevő csapatok szorosan együtt tudnak működni egymással és önszerveződőek. A folyamatok körkörös ciklusokban zajlanak (tervezés, implementálás, tesztelés, kiértékelés), ami nagyfokú rugalmasságot kölcsönöz a fejlesztési projektnek. SCRUMA SCRUM alighanem az egyik legelterjedtebb és legdivatosabb fejlesztési módszer, mely az agilis módszertanokhoz tartozik. Kis létszámú, 6-8 fős fejlesztői csapatokra épít, melyekben jellemzően 2-2 tesztelő van. A munka előrehaladásáért és a csapat összetartásáért a scrum master felel, míg az operatív irányításért a vezető fejlesztő. A csapathoz ideális esetben egy üzleti elemző is tartozik, aki az üzleti folyamatok oldaláról érti a szoftver működését. Tesztelési szempontból több csapat összehangolt tesztelői tevékenységét a tesztmenedzser végzi, aki teljes munka folyamatos előrehaladása felett őrködik. A SCRUM a munkákat általában hetekre és napokra bontja. A heti bontást sprintnek nevezik. Megjegyezzük, hogy egy sprint időtartama lehet több is egy hétnél. A napi bontás alatt a napokat indító megbeszéléseket kell érteni, mely elsősorban a csapat tagjainak szól és csak másodsorban a vezetőségnek. A napi megbeszélés (daily standup meeting) elsődleges célja annak tisztázása, hogy milyen feladatok lesznek az adott napon és általában hogyan halad a csapat a munkájával a terhez képest. A negyedéves, féléves, esetleg éves szoftverkiadások adhatják meg a munkák tágabb kereteit. Ilyenkor általában a projekten dolgozó összes csapat összegyűlik és a vezetők kiértékelik az elért célokat. Ezek a megbeszélések egyben fel is vezetik az újabb fejlesztési ciklust, ami így végeredményben egyenes folytatása az előzőnek. Természetesen jóval több szerepkör létezik egy-egy projekten belül, mint például a product owner, vagy a projektmenedzser stb., ám ezek tesztelői szempontból kevésbé érdekesek. Tesztszintek:KomponenstesztA komponenstesztek tipikusan izoláltan is végrehajtható tesztek egyszerűbb programok, szoftvermodulok, vagy programozási egységek, például osztályok vonatkozásában. Mivel ez a tesztelési szint erősen forráskód közeli lehet, így gyakori, hogy a tesztelésben aktívan segédkezik maga a forráskód írója is. A teszt-vezérelt fejlesztés során a forráskód eleve úgy van megírva, hogy (lehetőleg automatizáltan) komponensteszteket lehessen végrehajtani rajtuk. Integrációs tesztAz integrációs tesztek a komponensek egymás közötti, vagy az operációs rendszerrel, csatolófelületekkel stb. történő sikeres együttműködésének a vizsgálatát célozzák. Különösen nagyobb rendszereknél fontos a fokozatos, egymásra épülő tesztelés, mert átgondolatlan vagy hanyag megközelítéssel nehéz és tovább tarthat a hibák valódi okának megállapítása, ami jelentős és felesleges költségeket okozhat. RendszertesztA rendszertesztek tulajdonképpen az éles működésű rendszert hivatottak modellezni és vizsgálni ahhoz minél jobban hasonlító tesztkörnyezetben. Éles rendszeren végzett átfogó rendszerintegrációs tesztelés (például egy új rendszer bevezetése) szóba sem jöhet! A rendszertesztek a rendszer egészének a működését vizsgálják, kevésbé az egyes funkcionalitásokra. Elfogadási tesztA rendszertesztek után többféle, ún. elfogadási teszt végrehajtására is sor kerül. Ezen tesztek célja annak megállapítása, hogy a szoftver (rendszer) valóban képes ellátni a feladatát az elvárt módon. Ezeket hivatásos tesztelők, külső hivatásos tesztelők, vagy maguk a megrendelők, esetleg végfelhasználók végzik. Az elfogadási tesztek típusai:
Teszttípusok:Funkcionális tesztA funkcionális tesztek a szoftver előre meghatározott / dokumentált, konkrét funkcióit vizsgálják. Ezek a tesztek tipikusan ún. feketedoboz tesztek, amelyek a szoftver belső struktúrájának ismerete nélkül, mintegy „kívülről szemlélődve” kerülnek végrehajtásra. A funkcionális teszt azt vizsgálja, AMIT a szoftver csinál. A funkcionális tesztek alapja mindig egy dokumentum. Ez legrosszabb esetben egy felhasználói kézikönyv, ám erre a célra külön dokumentumokat, ún. funkcionális specifikációkat célszerű készíteni. Ezek a leírások ugyanis olyan technikai információkat, illetve folyamatleírásokat is tartalmaznak, melyekre egy átlagos végfelhasználónak ugyan nincsen szüksége, ám a tesztelés szempontjából életbe vágó lehet. Egy ügyfélnyilvántartó szoftver esetében külön leírás szólhat például egy új ügyfél felvételéhez szükséges lépésekről, de akár arról is, hogy a folyamat során az adatok mely rendszereken mennek keresztül, hol és hogyan tárolódnak stb. Egy kellő részletességű leírás alapján elkészíthetőek a tesztesetek, tesztlépések. Funkcionális teszteket bármely tesztszinten végre lehet hajtani. Nem funkcionális tesztA nem-funkcionális teszt a szűkebb-tágabb értelemben vett szoftver számszerűsíthető ismérveit vizsgálja; azt elemzi, hogy az adott szoftver valamit HOGYAN csinál, vagy valamilyen feltételnek milyen mértékben felel meg. Tipikus nem-funkcionális tesztek: teljesítményteszt, terheléses teszt, használhatósági teszt, megbízhatósági-, hordozhatósági teszt stb. Nem-funkcionális teszteket bármely tesztszinten végre lehet hajtani. Regressziós tesztA regressziós teszt egy már letesztelt szoftver ismételt tesztelését jelenti. Ezen teszt elsődleges célja az, hogy ellenőrizze a korábban már sikeresen tesztelt szoftvertulajdonságok helyes működését. Egy hiba kijavítását szintén regressziós teszteléssel szokás ellenőrizni. Előfordulhat, hogy a hiba csak részben, vagy egyáltalán nem tűnt el, sőt, a hibajavítás akár más helyen is (újabb) hibát vált ki. 5. TesztprojektekA tesztprojekt szerepkörei:A legfontosabb szerepkörök:
TesztmenedzserA tesztmenedzser legfontosabb feladata a tesztelés szinkronban tartása a fejlesztéssel, a tesztelői csapatok munkájának monitorozása és a tesztelők folyamatos informálása. Ha ezek közül bármelyik rész biceg, a tesztelési tevékenység egy párhuzamos dimenzióba kerül, mely köszönő viszonyban sincsen az eredeti valósággal. A tesztelésnek a fejlesztéssel történő szinkronban tartása adja az alapját maguknak a teszteknek, elvégre csak annak a tesztnek van értelme, amely a legaktuálisabb fejlesztésekből indul ki. A tesztek előrehaladásáról és a teszteredményekről a menedzsernek mindig friss információkkal kell rendelkeznie, mivel a tesztmenedzser tud végleges és átfogó képet adni a tesztprojekt aktuális eredményeiről. ProjektkoordinátorFontos további feladata, hogy a tesztelőket mindig ellássa a munkájukhoz szükséges információkkal és eszközökkel. Ez ugyanis NEM a tesztelő feladata, hanem a menedzseré. A menedzseri munkából kifolyólag elengedhetetlen az empátia és a humánus, emberközeli hozzáállás is. Mindig szem előtt kell tartania, hogy különböző habitusú emberekkel dolgozik. A gyakorlatban ez általában valóban így is van. A tesztmenedzser elsősorban vezető, nem pedig tesztelő. Ennek megfelelően nem feladata a tesztelés mikromenedzselése. Üzleti elemzőAz üzleti elemző mind a fejlesztők, mind a tesztelők munkáját segíti. Feladata a folyamatok és a kitűzött célok gyakorlati megvalósulásának megértése, ennek írásos formában történő rögzítése és a felmerülő akadályokról, ellentmondásokról a projekt felsőbb vezetésének tájékoztatása. Az üzleti elemzők gyakran az adott szoftvertípus professzionális, korábbi felhasználói közül kerülnek ki. Az üzleti elemzők feladata annak támogatása is, hogy a tesztelők rendelkezésére álljanak mindazon információk és leírások, melyalapján a tesztelés elvégezhető. Tesztkoordinátor, tesztvezetőA tesztkoordinátorok szerepe hasonló a tesztmenedzserekéhez, azzal a különbséggel, hogy kisebb tesztelői csapatok munkáját koordinálják. Lényegében a tesztmenedzser „helyi megbízottjai”. A tesztkoordinátorok általában maguk is tesztelők, akik tapasztalatuk révén képesek átlátni egy projekt kihívásait és feladatait, valamint ezt kommunikálni is tudják, elsősorban a tesztmenedzser és a többi tesztelő felé is. TesztelőA tesztelő a gyakorlatban végrehajtandó tesztek megtervezéséért, dokumentálásáért, végrehajtásáért és kiértékeléséért felel. A tesztelőkre gyakorta igen nagy nyomás nehezedik, mivel a projekt számos résztvevője megpróbálja érdekeit rajtuk keresztül érvényre juttatni. Ilyen esetekben a professzionális tesztelői hozzáállás az objektivitás megőrzése, ami a rugalmas hozzáállás mellett bizonyos fokú keménységet és persze rutint is igényel a nyomás elhárítására. A tesztprojekt fázisai:A tesztelés fázisai egymás után következnek, de a valóságban körkörös, visszatérő folyamatokról van szó. Egy folyamat tehát akár menet közben is változhat, annak ellenére is, hogy korábban már kilettek dolgozva. Egy-egy apróbb változtatásnak komoly pénzügyi vonzata is lehet, ezért ez a kérdés nem triviális, bár sokszor sokan elkövetik azt a hibát, hogy nem vesznek tudomást róla. A legfontosabb fázisok:
Tervezés, becslésA tervezés a projekt előkészítő fázisában történik, amikor a program megírása még nem történt meg. A tervezés során tisztázni kell, hogy mit és milyen szempontból kell majd tesztelni. Ez nem csak azért fontos, mert egy szoftvert teljes mértékben nem lehet soha letesztelni, hanem azért is, mert minél többféle típusú tesztet hajtunk végre, a tesztelés annál drágább lesz. A tervezés során a tesztmenedzser, a tesztelők véleményét is figyelembe véve megbecsüli, hogy mely teszttípusokkal, hány tesztelővel stb. milyen eredmények elérésére van lehetőség. A tesztstratégia tartalmazza a tesztek kivitelezésének pontos technikai részleteit és a tesztelés céljait. Projektindító (kick-off) meetingA kick-off legtöbbször egy informális megbeszélés, melyet a projektindulásakor szoktak megtartani. Legfontosabb célja a projekt szereplőinek bemutatása, a szerepkörök és felelősségi körök, valamint annak tisztázása, hogy a tesztelés elkezdésének nincsenek-e személyi-, ill. technikai akadályai. Tesztelői szempontból fontos annak tisztázása, hogy felmerülő kérdések esetén kihez lehet fordulni, ill. az is, hogy kiknek és milyen formában kell tájékoztatást adni a munkákról. Teszt dizájnA konkrét tesztek megtervezése a tesztelők felelőssége és feladatköre. Ez többnyire konkrét tesztesetek megírását, előkészítését jelenti, a projekt számára meghatározott szoftveres eszközök segítségével. TesztvégrehajtásA teszt végrehajtása a tesztesetben leírtak szerint történik. A végrehajtás a kiértékeléssel ér véget, ami valamilyen dokumentum, jelentés formájában ölt testet. Ellenőrzés, monitorozásA tesztek végrehajtását napi szinten érdemes és szükséges nyomon követni. Így azonnal kiderül, ha a tesztelés üteme elmarad a korábban tervezettől és az is, ha a szoftver minőségével kapcsolatban aggályok merülnek fel. A monitorozást a tesztmenedzser a tesztkoordinátor segítségével szoktak végezni. JelentéskészítésEgy-egy nagyobb tesztfázis közben és végén is külön jelentések, összefoglalók készülhetnek, melyek elsősorban a menedzsment számára hordoznak információkat a projekt előrehaladásával, a szoftver minőségével kapcsolatban. 6. TesztkiértékelésA tesztek kiértékelése az elvégzett munka dokumentálását jelenti. Elsődleges célja a feltárt hibák rögzítése. Ehhez hozzátartozik a hiba rögzítésének körülménye is. A tesztelő feladata mindig az, hogy a meglévő keretek között maximális pontossággal és részletességgel, de terjengősség nélkül rögzítse a hibákat. Ennek elmaradása és utólagos pótlása későbbiekben plusz erőforrásokat, elsősorban időt igényel a résztvevőktől, ami megdrágíthatja a projektet. Hibák dokumentálásaA hiba elnevezéseA hiba elnevezése általában egy rövid, mondatnyi szöveg. A modern hibarögzítő rendszerekben a leírás, vagy összegzés egyfajta címként is felfogható. Célja, hogy már ránézésre is tudni lehessen, milyen jellegű hibáról van szó, a hiba javításakor pedig azonnal azonosítani lehet a hibát és annak aktuális feldolgozási állapotát. HibaleírásA hibaleírások legfontosabb elemei szoftverek esetében:.
Fontosság (prioritás) és súlyosságA prioritás mindig a hiba kijavításának a sürgősségét jelenti.. A hiba súlyossága (severity) azt fejezi ki, hogy mekkora mértékű a hiba kihatása.. Egy súlyos hiba jellemzően magasabb prioritású is, de ez nem szükségszerű. Ha egy rendkívül súlyos hiba fellépésének igen kicsi a valószínűsége, akkor annak kijavítása lehet alacsony prioritású. De egy minimális kihatású hiba is lehet kiemelt prioritású, ha nagy eséllyel előfordul, vagy gyorsan kijavítható. Például, ha egy webes alkalmazás nyitó oldalára a céges logó helyett a szórakozott programozó csak egy vázlatot tesz ki, az ugyan nem befolyásolja a szoftver helyes működését, tehát alacsony súlyosságú, mégis gyorsan javítani kell, tehát kiemelt fontosságú. ÉrvényességA hiba érvényességét nem feltétlenül a tesztelő dönti el, ugyanis érvényesség alatt azt is érthetjük, hogy a hiba kijavítása egyáltalán meg fog-e történni. Elképzelhető olyan hiba is, mely a való életben soha nem fordulhat elő, bár mesterségesen előidézhető. És ritkán születhet olyan üzleti döntés, mely a hiba kijavítását elutasítja, ha például nincs rá pénz. Hozzárendelés meghatározásaEgy hibát annál hamarabb kijavítanak, minél hamarabb kerül a megfelelő személyhez, csapathoz stb. Elsősorban nagyobb vállalatoknál, ahol sok csapat dolgozik egy projekten, a felelősségi körök élesebben meg vannak szabva. A hozzárendelés megkönnyítéséhez fontos meghatározni, hogy ki a kompetens egy adott hiba esetén. Ez projektenként más és más. Tapasztalat, rákérdezés útján, vagy közvetlen instrukciók (pl. tesztstratégia dokumentuma) alapján lehet eldönteni egy-egy hiba felelősségi körét. Kisebb cégeknél a hibákat összesítik, ahonnan minden fejlesztő kaphat javítási munkát.Teszteredmények kiértékeléseNéhány tipikus kiértékelési szempont:
7. Tesztelés a gyakorlatbanA szoftvertesztelés napi gyakorlataA tesztelők jellemző napi tevékenységei:
A projektek egyedi ritmusának megfelelően, bizonyos időszakokban a tesztesetek tervezése és elkészítése kaphat hangsúlyt, míg máskor a tesztek végrehajtása, vagy éppen a korábban felvett hibák ellenőrzése. Nem ritka, hogy ezek a tevékenységek sokszor átfedésben vannak. Jó és hasznos, ha minden nap vannak legalább csapaton belüli megbeszélések, akár informálisak is. Ez segít minden résztvevőnek abban, hogy ne maradjanak le a többiektől információk tekintetében. Minden munkafázis fontos része a kommunikáció. A tesztelő kommunikál a programozókkal, a menedzserrel, ritkább esetben az ügyfelekkel is. A tesztek továbbfejlesztése nagyon fontos, sajnos erre kevesebb időszokott jutni a kelleténél, ennek kivitelezése sokszor a tesztelő leleményességétől is függ. Természetesen információkat a tesztelőnek is szolgáltatnia kell a munkájáról. Ennek módja is projektfüggő. Van, ahol napi szintű jelentések kötelezőek, valahol a heti egy alkalom is bőven elég. Az ún. riportolás egy kevésbé kedvelt tevékenység, ám helye van a tesztelési tevékenységek között. Az alkalmazott szoftvereszközök cégenként, sőt projektenként is szinte mindig mások. Ezek használatáról legtöbbször vezető fejlesztők és menedzserek döntenek, ritkábban egy sok tapasztalattal rendelkező tesztelő is beleszólhat ebbe. Hogyan teszteljünk például egy porszívót?A válaszhoz szükséges információk:
Porszívó tesztelésének a folyamata:
Mi várható el egy tesztelőtől? A feladatot először is értelmezni kell. Minden olyaninformációt be kell gyűjtenünk, ami nélkül a tesztelés megtervezése és biztonságos kivitelezése nem lehetséges. A tesztek tervezése során minden feladatot elemi lépések sorozatára kell bontanunk, figyelembe véve azok esetleges egymásra utaltságát. A porszívós példán keresztül valójában minden tesztfeladat modellezhető. Hogy csak két példát említsünk. Negatív teszt lehet annak megkísérlése, hogy egy maroknyi golyóstollat fel tud-e szívni a porszívó és közben mi történik. Terheléses teszt lehet az, ha a porszívót 24 órán keresztül üzemeltetjük. Gyakorlati példa: webes felhasználói azonosítás teszteléseA feladatAdott egy webes alkalmazás (weboldal), mely felhasználói profilokat is támogat, azaz külön be lehet jelentkezni felhasználói adatokkal. A bejelentkezés a weboldal kezdőoldalán található „Bejelentkezés” linkre történő kattintással kezdeményezhető. Ezután egy dialógusablak jelenik meg, ahol meg lehet adni felhasználói nevet, jelszót, majd a „Belépés” nyomógombra történő kattintással lehet ténylegesen bejelentkezni. A tesztelés célja, hogy manuális teszteléssel ellenőrizzük, hogy a regisztrált felhasználók be tudnak-e jelentkezni a weboldalra, felhasználói azonosítójuk ÉS jelszavuk megadásával. Ilyenkor az „Üdvözöljük, kedves felhasználónk!” üzenet jelenik meg. Ellenben nem regisztrált felhasználók ezt ne tehessék meg, és nem regisztrált felhasználói név, vagy jelszó használata esetén egy hibaüzenetnek kell megjelennie: „A megadott felhasználó nincs regisztrálva!” Amennyiben a felhasználói név, vagy jelszó bármelyike nincsen megadva, „A felhasználói név, vagy jelszó nincsen megadva!” üzenetnek kell megjelennie. A tesztelés a weboldal felületén történik. Mozilla Firefox böngészővel történő tesztelés elegendő. A tervezésA feladat leírását megnézve látszik, hogy alapvetően kétféle eredmény elérésére törekszünk: a sikeres és a sikertelen bejelentkezés működését kell vizsgálnunk, a megadott leírásnak megfelelően. Ehhez ún. pozitív és negatív tesztesetekre lesz szükségünk. Pozitív teszt szcenárióPozitív teszt szcenárió: Bejelentkezés érvényes felhasználói név és jelszó párossal. Negatív teszt szcenárióNegatív teszteseteknél, ahol több lehetséges kombinációt kell kipróbálnunk, ún. döntési mátrixot is készíthetünk. Ez valójában nem más, mint egy táblázat, ami segít átlátni a lehetséges kombinációkat. Ezek segítségével már sokkal könnyebb is megírni teszteseteket. A mátrix soraival azt jelöljük, hogy mely adatot adunk meg a tesztsorán. De jelölhetjük vele azt is, hogy érvényes/érvénytelen bejelentkezési adatokat adunk-e meg. 
A mátrix alapján legalább 6 féle negatív szcenáriót állíthatunk fel:
JóváhagyásAz elkészített teszteseteket jóvá kell hagyatnunk. Az ellenőrzést végezhetik más tesztelők, de akár a tesztmenedzser is, az üzleti elemző, esetleg az ügyfél bevonásával. Észrevételek esetén módosítani kell a terveket, majd ismét jóváhagyatni az átdolgozottakat. Ha mindenki elégedett, akkor elkezdődhet a tesztesetek kidolgozása. KivitelezésKivitelezés alatt itt a tesztesetek megírását és a tesztek végrehajtását értjük. AEzek a gyakorlatban időben általában elkülönülő fázisok, itt az egyszerűség kedvéért összevonjuk őket egy lépésbe. A végrehajtáshoz elengedhetetlen, hogy legalább egy érvényes felhasználói név / jelszó párossal rendelkezzünk (tesztadatok fontossága), mivel bizonyos tesztekhez ez kell, mint láttuk. Erre figyelnünk kell. Ha nem rendelkezünk ilyenekkel, jelezni kell, például a tesztmenedzsernek. A fenti tesztszcenáriók közül a negatívokat össze is vonhatjuk egyetlen tesztesetté, ez átláthatóbbá teszi a tesztek majdani végrehajtását. A pozitív teszteset és az összevont negatív teszteset ismertetése:
Teszteset neve: Felhasználói bejelentkezés, pozitív: 
Teszteset neve: Felhasználói bejelentkezés, negatív: 
A tesztlépések „Elvárt eredmény” oszlopához nem írtuk külön, redundánsan mindenhová oda, hogy az adott művelet közben fellépő bármely hiba tolerálható-e vagy sem. Általában nem. Egy adott hiba ugyanis jó eséllyel befolyásolhatja akár a bejelentkezés sikerességét is. Az ehhez hasonló esetekben vagy a tapasztalat, vagy egy tapasztaltabb kolléga tanácsa segíthet. Ha például a weboldalkezdő képernyőjén az egyik statikus szöveg el van csúszva a képernyőn, az nyilván hiba, de nem befolyásolja a felhasználói bejelentkezés sikerességét. Ha viszont a „Bejelentkezés” link annyira el van csúszva, hogy nem is lehet rákattintani a böngészőben, az már egyenesen lehetetlenné teszi a bejelentkezést és a tesztvégrehajtás befejezését. Ebben az esetben a hibát dokumentálni kell, és a teszt blokkolt státuszba kerül: mindaddig nem folytatódhat a tesztvégrehajtás, amíg ez a hiba ki nem lesz javítva. Bármely esetben, amikor a bejelentkezéssel kapcsolatos elvárt eredmény nem teljesül, dokumentálnunk kell a hibát. Amennyiben a teszteset fő célja nem teljesül, maga a teljes teszt is hibásnak minősül. Felfedezéses tesztelés esetén nem az előre elvárt sorrendben hajtanak végre művelteket, hanem véletlenszerű sorrendben. Ezáltal esetlegesen hibák idézhetők elő Ez egy kötetlenebb tesztelési forma, mely ad hoc cselekvéseken alapul, ezért nem feltétlenül lehet rá előre teszteseteket sem írni. A tesztek „utóélete”Egy teszt végrehajtása után egy rövid, formális, vagy kevésbé formális (projektfüggő) összefoglalót kell írni a tesztről melyet röviden, a tényekre alapozva. Amennyiben hibákat találunk, nagyon röviden ezekre is érdemes kitérni a jelentésekben. Amennyiben a hibát a programozóknak sikerült kijavítaniuk, a javítást ismét ellenőriznünk kell, a korábban a hiba által érintett teszt ismételt végrehajtásával. A kreatív tesztesetekrőlA tesztelőt a valóságban kötik azok a keretek, melyeket a tesztelés számára szerződésben is külön rögzíteni szoktak. A megrendelő azt szeretné kapni, amiért fizet. A kivitelező pedig legtöbbször csak azt a munkát hajlandó elvégezni, amivel megbízták. A riportjainkban, beszámolóinkban célszerű felhívni a figyelmet az esetlegesen szükséges további tesztek fontosságára, azaz javaslatokat teszünk. Tapasztaltabb tesztelőktől ezt el is várják. Ebben az esetben tesztelőként a lehető legmesszebb elmegyünk, a döntés meghozatala azonban már a menedzserek, ill. az ügyfél kezében lesz. Szoftvertesztelés Magyarországon és a nagyvilágbanMinden cég a saját folyamatainak keretei közé igyekszik beszuszakolni a fejlesztési és tesztelési módszertanokat. Közben bizonyos aspektusokra nagyobb, másokra, nos, mondjuk úgy, kevesebb hangsúlyt fektetnek. Egy biztos: nincs két ugyanúgy alkalmazott tesztelési gyakorlat. Jelenleg a manuális tesztelésről az automatizált tesztelésre történő átállás a divat. Ez részben természetes és indokolt is, részben viszont a trendek sokszor ész nélküli követésével találkozhatunk. Jó példa erre, hogy sok cég egyenesen a manuális tesztelés automatizált teszteléssel történő kiváltását hangoztatja, ami nyilvánvalóan butaság, hiszen a két teszt nem konkurálhat egymással, lévén két egymást kiegészítő teszttípusról van szó. Egy-egy tesztelési program bevezetése gyakran egy vég nélküli, rosszul menedzselt bukdácsolás, mintsem professzionálisszakmai tevékenység. Rosszabb esetben a vezetők szerint a fejlesztőknek eleve tökéletes munkát kell végezniük, ami azt is jelenti, hogy vannak cégek, ahol a tesztelés szükségességét még bizonygatni kell a vezetőség előtt. Ilyen esetekben nem ritka, hogy torzmunkaköröket hoznak létre, mint például a „fejlesztő-tesztelő”, ami szakmai abszurdum. A tesztelésre helyenként mint menet közben elsajátítható ismeretekre építő, egyszerű betanított munkára tekintenek, mintsem hivatásra A tesztelői munka teljes embert kívánó feladat! Külföldön egy kicsit jobb a helyzet. A különbség talán annyi, hogy tőlünk nyugatabbra egyre inkább professzionális, autonóm szakterületté kezd fejlődni a tesztelés, ahol a képzések és a gyakorlat egyaránt nagy súllyal esnek a latba. Tesztelés nagygépes környezetbenA legtöbb nagyvállalat szerverparkokat, szuperszámítógépeket üzemeltet, ahol speciális, szerverekhez kifejlesztett operációsrendszerek is üzemelnek, mint például a Microsoft Windows Server, a UNIX-alapú AIX, Solaris, Linux és társaik. Ezen rendszerek, továbbá különféle adatbázisrendszerek alapvető ismerete mindenképpen szükséges egy tesztelő számára. Ezek egyébként tipikusan multinacionális munkakörnyezetek, ezért az informatikai tudás mellett az idegen nyelvek ismerete is kiemelten fontos. Nem ritka, hogy más országokban dolgozó, más nyelvet beszélő kollégákkal kell együttműködni a tesztelés sikeres lebonyolítása érdekében. Tesztelés mobileszközökönA mobilfejlesztés felfutott üzletág lett ugyan, ám a mobiltesztelés mint olyan korántsem nevezhető egységes, elfogadott gyakorlatnak. Mobilalkalmazásokat tesztelni nem egyenlő pusztán azzal, hogy az ember kézbe vesz egy okostelefont, vagy tabletet és elkezdi nyomkodni. A mobilvilág nagyon heterogén, a kompatibilitás, egységesség biztosítása pedig állandó kihívás a fejlesztők számára. Ráadásul egy üzleti alkalmazás nem önmagában fut, hanem aktív kommunikációt folytat más rendszerekkel is. Egy mobilalkalmazás tesztelése komplex integratív szemléletű feladat. Ebbe a kategóriába sorolhatjuk a weboldalak, webes alkalmazások mobileszközökre optimalizált változatait is. Mobilalkalmazásokat valódi mobileszközökön, vagy asztali számítógépes szimulátor alkalmazásokkal is lehet tesztelni. A tesztmenedzser feladata (és felelőssége) eldönteni, hogy melyiket és milyen mértékben alkalmazzák a tesztelés során. A tesztelést nem elegendő egyetlen típusú eszközön elvégezni, hanem több, különböző teljesítményű és tulajdonságú eszközre (vagy konfigurált szimulátorra) van szükség. A különbözőségeknek elsősorban a képernyők mérete, felbontása, az eszköz processzorának és háttértárolójának a kapacitása tekintetében van jelentőségük. Megemlítjük, hogy a korszerű mobileszközökön szintén fontos kérdés a weboldalak, webes alkalmazások különböző elérhető mobilos böngészőkkel történő tesztelése. Pár szó az XML formátumrólAz XML formátummal számos esetben találkozhatunk az informatikában, leírásával egész könyvek foglalkoznak. Aki látta már a HTML oldalak forráskódját, annak jó kiindulási alap lehet az XML megértésében a HTML tag-ek szerkezete. Az XML egy szöveges formátum, mely az adatokat szimbolikusnevek hierarchikus szerkezetébe ágyazva tartalmazza. Vegyünk egy egyszerű példát! Példánkban térinformatikai adatok tárolását mutatjuk be. A tárolandó adat legyen egy buszmegálló, melynek pontos földrajzi koordinátája van, például ez: 19.05 és 47.23. Ez XML-ben így is kinézhetne: 
A koordinátákat a longitude és latitude blokkokban adjuk meg, melyek egyértelműen jelzik, hogy mely koordináták a hosszúsági és melyek a szélességi koordináták. Mindkét koordináta egy nagyobb egység része, a coordinates blokké, ami egy másik blokkba, az objektum blokkba tartozik. Az XML tagek rendelkezhetnek tulajdonságokkal (csakúgy, mint a HTML-ben), példánkban az objektum típusát adjuk meg („bus stop”). Az objektumokat szintén nagyobb egységek alá rendelhetjük, például települések, megyék, országok stb. blokkokba. Egy adott szinten pedig több ugyanolyan elem is állhat. 
Tesztelést támogató szoftverek a gyakorlatbanTesztelés a Quickteszt segítségévelA QuickTest bemutatása A QuickTest egy tanulásra és demonstrációs célokra használható tesztdokumentációs minirendszer, mely egyelőre böngészőből érhető el. A nyílt forráskódú Flex keretrendszerben készült, böngészős futtatásához Flash player szükséges. A saját készítésű rendszer teljesen ingyenesen hozzáférhető. Mivel működő rendszerről van szó, testreszabott formában akár éles projekteknél is használható. A nyilvános változat néhány egyszerű megkötést tartalmaz, például ki vannak kapcsolva a törlési műveletek. Előnye az ingyenesség mellett egyszerűsége: nagyon könnyen megérthető vele a tesztrendszerek működése, még laikusok számára is. Technikai hátterét Apache webszerver és MySQL adatbázis adja, melyet PHP szkriptek segítségével ér el a rendszer. Az alkalmazás kezdőképernyőjén érhetjük el a főbb funkciókat: 
Projektek kezelése Az alkalmazás kezdőképernyőjén válasszuk ki a 'Manage Projects' lehetőséget! Ekkor a projektek adminisztrációs felületére jutunk, ahol projektjeink listája látható. Kezdetben ez üres. Lehetőségünk van létrehozni, módosítani és törölni projekteket. 
Az egyszerűség kedvéért a projektek egyetlen tulajdonsággal rendelkeznek, ez a nevük. Kattintsunk a 'Create' gombra egy új projekt létrehozásához! 
A 'New Project' oldalon adjunk meg egy nevet, első projektünk neve legyen „Project A”! Kattintsunk a 'Create' gombra! Ekkor visszakerülünk a projektek listáját tartalmazó oldalra. A lista immár tartalmazza új projektünket is. 
Hozzunk létre egy másik projektet is, „Project B” néven! Most már két projekttel rendelkezünk. 
A projektek neveit egyszerűen frissíthetjük. Ehhez először ki kell választanunk a projektet a listánkból, majd az 'Edit' gombra kell kattintanunk. Ekkor frissíthetjük a projekt nevét, amit az 'Update' gombra történő kattintással nyugtázhatunk. Nevezzük át a „Project A” projektet „Project 1”-re, és a „Project B”-t„Project 2”-re! 
Ha mindent jól csináltunk, projektjeink már az új névvel szerepelnek a listában. 
Térjünk vissza a főképernyőre a 'Cancel' gombra történő kattintással! Csapattagok kezelése Az alkalmazás kezdőképernyőjén válasszuk ki a 'Manage Team' lehetőséget! A csapat adminisztrációs felülete teljesen megegyezik a projektek kezelésével. 
A projekteknél megismert módon hozzunk létre két tagot. Példánkban ez legyen a „Tester 1” és „Tester 2”! 
Ha elkészültünk, térjünk ismét vissza a kezdőképernyőre! Tesztesetek létrehozása Most már van két projektünk és két tesztelőnk is. Ezek segítségével már létrehozhatunk teszteseteket és hibajegyeket is. Az előbbivel kezdjük. Ehhez az alkalmazás kezdőképernyőjén válasszuk ki a 'Manage Test Cases' lehetőséget! 
Mint látjuk, a tesztesetek kezelőfelülete nagyban hasonlít a projektek és a csapattagok adminisztrációs felületéhez. Azonban három új elemet is találunk itt:
Az utolsó két lehetőséggel villámgyorsan szűréseket hajthatunk végre teszteseteinken, így mindig csak azokat látjuk, amelyek érdekelnek minket. Erre az ad lehetőséget, hogy minden tesztesethez projektet és egy csapattagot kell rendelnünk. A két szűrőlista tartalma mindig dinamikusan frissül, azaz csakolyan csapattagok és projektek nevei választhatóak ki, melyek garantáltan léteznek. Erről egyszerűen megbizonyosodhatunk, ha például lenyitjuk az 'Assignee' listát. A lista a „Tester 1” és „Tester 2” elemeket tartalmazza, ezeket hoztuk létre korábban. Mindkét szűrőlista tartalmaz egy „All” elemet is, ez az alapbeállítás is egyébként. Kiválasztva az alkalmazás a lista összes elemét figyelembe veszi a tesztesetek kilistázásánál. 
A 'Test Steps' gomb csak akkor működik, ha már létrehoztunk legalább egy tesztesetet és ki is választjuk azt a listából. Ezt fogjuk tenni most. Kattintsunk a 'Create' gombra! A megjelenő ablakban meg kell adnunk tesztesetünk nevét, azt, hogy mely projekthez tartozik, melyik csapattaghoz rendeljük és mi a teszteset státusza. 
A fenti példában a „Teszteset 1” tesztesetet a „Project 1” projekthez rendeltük, az egyes tesztelőhöz. A teszteset státusza „New”, azaz „Új” lesz. A beállítható státuszok:
Tesztlépések kezelése Ha már létrehoztunk legalább egy tesztesetet, azokhoz tesztlépéseket hozhatunk létre, melyek pontosan leírják, hogy az adott tesztet hogyan kell végrehajtani. Az alábbi képen már két tesztlépést hozzáadtunk tesztesetünkhöz és éppen a harmadikat is készülünk hozzáadni. 
Új tesztlépést az 'Add' feliratú gombbal tudunk hozzáadni a tesztesetünkhöz, de ehhez meg kell adnunk a tesztlépés számát ('StepNumber') és a lépés leírását. A már létrehozott tesztesetek az „All test steps” listában találhatóak. A tesztesetek sorrendje a lépések számozásától függ. Egy lépést így áttudunk helyezni pusztán a lépés számának frissítésével is. Egy tesztlépés módosításához előbb ki kell választanunk a listából. Ezután frissíthetjük az 'Update' gombbal, vagy akár törölhetjük is a 'Remove' gombra kattintva. Tesztlépést másolni úgy tudunk, hogy kiválasztjuk, majd az 'Add' gombra kattintunk. Érdemes mindig növekvő számozást alkalmazni a tesztlépésekhez. Jó gyakorlat, ha például eleve tízesével tesszük ezt, így a későbbiekben könnyű beszúrni újabb lépéseket is. Vegyük észre, hogy minden tesztlépéshez egy státuszt rendelhetünk. Ezeket a 'Set status' felirat alatti listában találhatjuk. Egyszerűen csak ki kell választanunk a kívánt státuszt. Az alapértelmezett érték az „In Preparation”. A tesztlépések lehetséges értékei:
Első ránézésre feleslegesnek tűnhet az a lehetőség, hogy mind teljes tesztesetekhez, mind egyes tesztlépésekhez külön is beállíthassunk státuszokat. A gyakorlatban ez a lehetőség nagyon is indokolt. Bonyolult tesztek végrehajtása ugyanis sokszor napokig, extrém esetben akár hetekig eltarthat. Ilyenkor bizonyos tesztlépések már kiértékelhetőek, mások viszont még végre sincsenek hajtva. A státuszok segítségével gyorsan képet lehet kapni egy teszteset végrehajtásának állapotáról. Gyakorlásképpen hozzunk létre egy újabb tesztesetet, hozzátartozót tesztlépésekkel! Hibajegyek létrehozása Amint azt a korábbi fejezetekben már megismertük, a hibajegyek segítségével a tesztelés során talált hibákat szokás rögzíteni. A hibajegyek létrehozásához és kezeléséhez az alkalmazás kezdőképernyőjén válasszuk ki a 'Manage Tickets' lehetőséget! A megjelenő ablak két fő részre osztható. A bal oldalon a hibajegyek listája található. A lista tartalmazza a hibák státuszát, az utolsó módosításuk dátumát és a jegyek címét. Többféle szűrőt is találunk itt, melyekkel a jegyhez rendelt személy, a projekt, a prioritás és a státuszalapján is szűrhetjük a jegyek listáját. Ha kiválasztunk egy jegyet a listából, a jobb oldalon jelennek meg a beállításai. Legfelül a jegy címe, azaz rövid leírása található, alatta pedig a részletes hibaleírás. A jegy projektje, a hozzárendelt személy neve, a prioritás és a státusz is automatikusan beállítódik. A kiválasztott hibajegyet az 'Update' gombbal frissíthetjük, illetve a 'Delete' gombbal törölhetjük. Szintén a jobb oldali beállítások segítségével új hibajegyet is készíthetünk a 'Create' gomb segítségével. 
A hibajegyekhez az alábbi prioritásokat rendelhetjük:
A lehetséges státuszok:
Hibajegyek létrehozása Az alkalmazás kezdőképernyőjén a 'Show Reports' lehetőséget kiválasztva különféle adatok jeleníthetőek meg, melyek a tesztesetekről és a hibajegyekről mutatnak számszerűsített információkat. 
Egy komplex jelentéskészítés ennél többet szokott jelenteni, jellemzően, gyakoriak a grafikonok és sok más összefüggés kimutatása is. A QuickTest margójára A fenti eszközökkel igen jól menedzselhető munkafolyamatokat alakíthatunk ki és hatékonyan támogathatjuk a tesztelést. A QuickTest egy, a teszteléssel történő ismerkedésre használható eszköz, de éles munkára is átalakítható. A következőkben megismerkedünk két kereskedelmi szoftverrel, melyeket éles tesztelésnél előszeretettel használnak. A QuickTest megismerése nem öncélú volt. Számos módszer vissza fog köszönni ezeknél a szoftvereknél is, ezeket most már sokkal könnyebben értelmezni tudjuk. SOAP UILetöltés és telepítés A SOAP UI ingyenes és kereskedelmi verzióban is elérhető, számos teszt típust és többféle technológiát támogat. A kereskedelmi verziósegítségével egyebek mellett könnyebben állíthatunk össze teszteket, de az ingyenes verzió is tökéletesen alkalmas tesztelésre. A szoftvert az alábbi oldalról érhetjük el és tölthetjük le: http://www.soapui.org/downloads/soapui/open-source.html 
A telepítés egy varázsló segítségével bonyolítható le. A telepítő első oldalán kattintsunk a Next feliratú gombra! 
Ezután a felhasználási feltételek elfogadása és a telepítés helyének kiválasztása következik. 
Többféle telepíthető komponenst kiválaszthatunk. Az alapértelmezett beállítások általában megfelelőek a legtöbb feladatra. 
A szoftver oktatóanyagokat is telepít a számítógépre, ezek helyét szintén megadhatjuk. 
A telepítés záró lépései megegyeznek a legtöbb Windows alkalmazás telepítésével. 
A folyamat végén még hírlevélre történő feliratkozási lehetőséggel is találkozhatunk, ez természetesen nem kötelező. 
Online tananyagok A webes oktatóleckéket az alkalmazás Help – Getting Started menüpontjával is megnyithatjuk. 
Ismerkedés a SOAP UI-val Az alkalmazás első indításakor a főképernyőt láthatjuk. Ennek két legfontosabb része a bal oldali navigációs terület, ahol projektjeink szerkezetében lépkedhetünk. Az ablak nagy részét a különböző szerkesztőablakok foglalják el a jobb oldalon. Itt módosíthatunk beállításokat és szerkeszthetjük tesztjeink adatait. 
A File – Preferences menüpont segítségével fontos beállításokat eszközölhetünk. Ezek közül a hálózati beállítások a kiemelten fontosak. 
SOAP UI létrehozásaA SOAP UI-ban projekteket hozhatunk létre, melyek számos tesztfeladatot egy egységbe fognak össze. Könyvünkben webszolgáltatások használatán keresztül mutatjuk be a SOAP UI projektek létrehozását és alapszintű használatát. Először is indítsuk el az alkalmazást, majd válasszuk ki a ‘File’ menü ‘New SOAP Project’ menüpontját! 
Ezt követően egy párbeszédablak jelenik meg, melyben nevet adhatunk a projektnek és itt adhatjuk meg a WSDL elérhetőségét is. A projekt neve tetszőleges név lehet. 
A WSDL esetünkben ez lesz: http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL Példánkban időjárási adatokkal kapcsolatos webszolgáltatást fogunk meghívni. 
Kattintsunk az OK gombra! A SOAP UI ekkor hosszabb-rövidebb ideig elemzi a szolgáltatás leíróját. 
Ezen információk alapján a projekthez automatikusan hozzáadódnak a rendelkezésre álló szolgáltatások teszthívásai. Esetünkben ezek a GetCityForecastByZIP, GetCityWeatherByZIP és a GetWeatherInformation lesznek. 
Megjegyezzük, hogy WSDL-t nem kötelező megadni projektlétrehozásakor. Ezt bármikor pótolhatjuk az ’Add WSDL’ menüponttal, melyet a projekt nevére történő jobb kattintással felhívott helyi menüből választhatunk ki. Ezzel sikeresen létrehoztuk első SOAP UI projektünket! A projekt finomhangolásaÚjdonsült projektünk nevére duplán rákattintva a projekt legfontosabb beállításait megjelenítő ablak jelenik meg. Ehhez hasonlóan, a projekthez tartozó szolgáltatás nevére történő dupla kattintással az adott szolgáltatás beállításait tekinthetjük meg. 
Teszthívás létrehozása a projektbenA navigátor ablakban a ConversionRate melletti + jelre kattintva megjelenik egy ’Request1’ listaelem, ami egy automatikusan létrehozott teszthívás. 
Ilyen teszthívásokat mi magunk is készíthetünk, ehhez kattintsunk a jobb egérgombbal a szolgáltatás nevére, majd válasszuk ki a ’NewRequest’ lehetőséget! Szintén a teszthívások nevére a jobb egérgombbal kattintva többféleműveletet hajthatunk végre ezeken, például át is nevezhetjük azt. 
Teszteset létrehozása és végrehajtásaAz előzőekben létrehozott projektünkkel fogunk tovább dolgozni. Kattintsunk duplán az előzőekben létrehozott ’Request1’teszthívásunkra! 
A megnyíló ablakban már közvetlenül szerkeszthetjük a teszthívásunkat, ami XML formátumú. Mielőtt azonban ezt megtennénk, létrehozunk egy tesztesetet. Ehhez kattintsunk a ‘Híváshozzáadása tesztesethez’ gombra (angolul: ‘Add this request to a TestCase’)! 
A megjelenő párbeszédablakban a létrehozandó tesztesetünket tároló tesztgyűjteménynek (‘TestSuite’) kell nevet adnunk, ez példánkban “Tesztcsomag” lesz. 
Az OK-ra kattintva a teszteset nevét is meg kell adnunk, legyen például “Teszteset1”! 
Az OK-ra kattintva tesztesetünk első tesztlépését hozhatjuk létre. Ez esetünkben egyetlen lépés lesz, melynek a „Teszthívás” nevet adjuk most. 
Ha mindent megadtunk, a SOAP UI felületén ehhez hasonló képet kell kapnunk: 
p> Látható, hogy projektünk szerkezetében egy új logikai egység jött létre, ’Tesztcsomag’ néven, mely tartalmazza a ’Teszteset1’tesztesetünket és a ’Teszthívás’ nevű tesztlépést is. A tesztesetünk részleteivel a jobb oldalon egy újabb ablak is megnyílt. Teszt futtatásaEgy meglévő tesztesetet a gombra történő kattintással tudunk lefuttatni. Ezt akár azonnal meg is tehetjük. Pár másodperc után a teszt lefut. A ’FINISHED’, azaz „végrehajtva” felirat zöld lesz, azaz sikeres a végrehajtás. Ez nem is csoda, hiszen nem is adtunk meg teszteredményre vonatkozó feltételt, így mindenképpen sikeres tesztről beszélhetünk. A feltételek megadásának módját hamarosan megismerjük, de előbb nézzük meg, mi történt a háttérben! 
Kattintsunk duplán a Teszthívás-ra a bal oldali navigációs ablakban! Így megjelenik a SOAP UI által a webszolgáltatást futtatószerverre küldött üzenet és a válasz is, mert a teszt futtatásával ez is automatikusan megtörténik. A jobb oldali mezőben látható a szerver válasza. Ezt a kérést küldtük el a szervernek: 
A válasz pedig ez lett (a kapott XML formátumú üzenetet rövidítve közöljük):
A válasz időjárási információkat tartalmaz, szolgáltatás hívásunkkal ezt kértük le. A szolgáltatás a GetWeatherInformation volt. Hívások kézi módosításaAz előző példában a szolgáltatás hívása egy alapértelmezett XML kérésen keresztül történt. A valóságban számos paraméter is szerepelhet az XML-ben. Következő példánkban a GetCityWeatherByZIP hívást fogjuk kézzel módosítani. A SOAP UI bal oldali navigációs sávjában keressük meg ezt a szolgáltatást, majd dupla kattintással nyissuk mega szolgáltatáshívás (request) szerkesztő ablakát! Az XML kérés ehhez hasonló lesz: 
A szolgáltatást így meghívva az alábbi választ kapjuk. 
A válasz SUCCES node-jának értéke FALSE. Ez azt jelenti, hogy a hívás nem volt sikeres. A hiba szöveges formában is meg van adva: „Invalid ZIP”, azaz érvénytelen irányítószámot adtunk meg. Ez igazis, hiszen a kérésünkben ennek értéke „?” volt. Megjegyezzük, hogy a hibákat más XML szerkezetekben is visszakaphatjuk, például „faultID”, „faultstring” node-ok közé zárva. Most megismételjük a hívást, de ezúttal érvényes irányítószámot adunk meg. Ez 10007 lesz, ami New York-hoz tartozik. Tehát: 
A kérésre adott válasz ezúttal eredményes lesz, számos, New Yorkkal kapcsolatos időjárási adatot kapunk vissza a válaszban: Most megismételjük a hívást, de ezúttal érvényes irányítószámot adunk meg. Ez 10007 lesz, ami New York-hoz tartozik. Tehát: 
Teszteredmények kiértékeléseA tesztek futása nem csak sikeres-sikertelen eredmények megállapításával végződhet. A SOAP UI lehetőséget kínál arra, hogy a válaszokat különböző szempontok alapján kiértékeljük. Ez lehet tartalmi, vagy formai kiértékelés is. Utóbbi lehet például a válaszidő elemzése. Erre mutatunk be egy utolsó példát. A navigációs sávban keressük meg a tesztlépések között a„Teszthívás”-t és dupla kattintással nyissuk meg! A kérés indítására használható gomb mellett kattintsunk a „Feltétel hozzáadása” gombra, ami egy zöld plusz jel. A feltétel a SOAP UI terminológiájában az ún. assertion. 
Megjelenik egy párbeszédablak, melyben különböző feltételeket adhatunk meg. 
Válasszuk ki az ‘SLA’-t, majd a jobb oldalon a ’Response SLA’ elemet! Ezt követően a párbeszédablakban kattintsunk az ’Add’ gombra! Ezután meg kell adnunk a válaszidő felső határát, ami esetünkben legyen 500 ezredmásodperc, azaz fél másodperc. 
Nyissuk meg tesztesetünket, majd futtassuk le azt! A teszt ezúttal sikertelen lesz, mert ahogyan a lenti képen is látható, a válasz 1347 ezredmásodpercig tartott, ami jóval több, mint a megadott 500 ezredmásodperc. 
Vegyük észre, hogy a „Teszthívás” elemünk színe szintén pirosra változott! Válasszuk ki ezt az elemet, majd nyissuk meg! 
A kérés ablakának alsó részén azt olvashatjuk, hogy a szerverválasza valid, azaz érvényes volt, ám a teszt feltétele nem teljesült. Kattintsunk duplán a „Response SLA - FAILED” sorra és adjunkmeg egy nagyobb értéket, mondjuk 1500 másodpercet! 
Természetesen a teszt feltételének módosítása éles teszt során nem változtatna semmit azon a tényen, hogy a szerver válasza alacsonyabb az elvártnál. Példáinkban csupán a SOAP UI alapszintű megismertetése volt a cél. 
JIRAA JIRA napjaink egyik legelterjedtebb folyamatmenedzselő rendszere. Támogatja fejlesztési, tesztelési folyamatok tervezését, nyomonkövetését és kiértékelését is. A rendszer támogatja továbbá a felhasználói profilokat is, így egyprojekt minden szintjének résztvevője testreszabott módon férhethozzá a projekttel kapcsolatos adataihoz. Az alkalmazás nagymértékben testreszabható, így minden projekt a saját szájíze szerint alakíthatja a működését és bizonyos keretek közötta megjelenését is. A JIRA bővíthető is, számos beépülő modult fejlesztenek hozzá. Mindezek mellett általános jegykezelő és tesztmenedzsment rendszerként is használható. Hazánkban sok nagyvállalat és kisebbvállalkozás is előszeretettel használja, ezért nagy valószínűséggel találkozhatnak vele a magyarországi tesztelők is. Elérhetőség A JIRA egy online, alapvetően webes felületre optimalizált alkalmazás. Egy fizetős szoftverről van szó, ám a rendszer alapfunkcióit bárki kipróbálhatja, ugyanis magának a JIRA-nak a fejlesztését is JIRA-val támogatják, sőt hibákat is egy e célból létrehozott nyilvános rendszeren keresztül lehet bejelenteni. Ennek az elérhetősége: https://jira.atlassian.com Ismerkedés a kezelőfelülettel A rendszer nyitóképernyője a Dashboard, mely gyakran tartalmaz aktuális információkat az aktuális, futó projektről. 
A nyitóoldal tartalma is testreszabható egyébként, előszeretettel jelenítik meg itt a felhasználók legutóbbi aktivitásait is, amit a felületre bejelentkezve mindenki láthat. A JIRA rendelkezik egy főmenüvel, melynek legfontosabb elem-ei a bal felső sarokban találhatóak: 
A három legfontosabb, mindennap használatos menüpont a következő: A Dashboards menüponttal különféle összefoglaló, áttekintőoldalakra juthatunk. Ez projektfüggő. A Projects alatt több projekt is szerepelhet, attól függően, hogy a felhasználó milyen más projektekhez van még hozzárendelve. Az Issues menüpont a hibajegyek kezeléséhez enged hozzáférést. Itt kereshetünk és hozhatunk létre hibajegyeket is. 
A Projects egyik menüpontjára kattintva megjelenik egy vertikális szimbólumsor is a bal oldalon. Ezzel további, általános oldalra juthatunk, például a projektriportokhoz. A Reports szimbólumot kiválasztva különböző, a projekt adataiból kinyert grafikont, összefoglalót tekinthetünk meg. A riportok tartalma természetesen testreszabható. 
Jegykezelés Talán a jegyek kezelése az a vezérfonal, ami köré a JIRA többi folyamata is felépül, ezért a jegyek kezelése alapfontosságú készségnek számít. A jegyek nem csak hibajegyek lehetnek, hanem bizonyos feladatokat is leírhatnak. A lényeg minden esetben az, hogy egy bizonyos munka minden munkafázisban végigkövethető legyen. Az ‘Issues’ – ‘Search for issues’ menüpontot kiválasztva az aktuális projekt összes jegyének listája megjelenik. 
A lista tulajdonképpen nem más, mint a JIRA adatbázisának a megjelenítése. A lista oszlopainak fejlécei vannak, melyekre rákattintva rendezéseket végezhetünk a listában. Az oszlopok láthatósága testreszabható, és meglehetősen sok van belőlük. 
A lista nézet kiváló, ha gyors áttekintésre van szükségünk a feldolgozásra váró jegyekről, ám részletek itt nem jelennek meg. A jegyek lista nézetét az ablak jobb felső részében elhelyezkedő beállítás szimbólumra kattintva válthatjuk át részlet nézetre. 
Ebben az elrendezésben jóval több minden látszik. Bal oldalon a hibajegyek azonosítója, címe látható egy listában, a jobb oldalon pedig minden adat elolvasható, amit a hiba bejelentője megadott. 
Ha a felhasználó jogosultsága megengedi, a jegyek tartalma azonnal módosítható is. Fejlesztők, illetve tesztelők általában rendelkeznek ilyen jogosultsággal. Keresések Az egyszerű kulcsszavas keresések mellett nagyon fontos, hogy a projekt résztvevői (így a tesztelők is), komplexebb kereséseket is végre tudjanak hajtani a JIRA-ban rögzített elemeken. A legegyszerűbb keresés a kulcsszavas keresés. A keresett kulcsszót a „Contains text” szövegmezőbe írhatjuk be. 
A nagyító ikonra kattintva a keresés már így is elindítható, de a ’More’ gombra kattintva megadhatjuk azt is, hogy mely mezőkre hajtódjon végre a keresés. Az ‘Advanced’ linkre kattintva még összetettebb kereséseket végezhetünk. Ilyenkor egy hosszabb szöveges beviteli mező jelenik meg, ahová mezőneveket és logikai kifejezéseket is megadhatunk. A beviteli mező gépelés közben intelligens javaslatokat tesz a még gyorsabb bevitel érdekében. Egy kifejezés megadása MEZŐNÉV EGYEZŐSÉGJEL ÉRTÉK hármassal történik, például: Name = Lajos. A kifejezések között kapcsolatokat is megadhatunk, ez általában ÉS szokott lenni (AND). Íly módon több kifejezést is összekapcsolhatunk. Az alábbi példában a Documentation típusú jegyeket keressük, de csak azokat, melyek egy bizonyos priorítással rendelkeznek. Ehhez az AND kulcsszót használjuk. 
A JIRA lehetőséget kínál arra, hogy kereséseinket névvel ellátva, profilunk adataként eltároljuk. Ehhez természetesen előbb be kelljelentkeznünk. A keresések találati listája ugyanolyan felépítésű, mint a fentebb tárgyalt listák. Ugyanarról a listáról van szó, csak ez keresésünk eredményeit tartalmazza. További szoftverekÓriási mennyiségű, ingyenes és kereskedelmi szoftver férhető hozzá manapság, melyekkel a szoftvertesztelés teljes munkafolyamata lefedhető. Hogy ezek közül melyiket használják egy cégnél, az részben szakmai, részben üzleti-pénzügyi döntés. Ez utóbbinak köszönhetően szinte mindenhol a kész megoldásokat preferálják. Egyedi fejlesztésekkel is lehet találkozni, de ezek igen ritkák. Dokumentációs mintákTesztesetek megfogalmazásaPéldánkban egy egyszerű dokumentumkezelő alkalmazás egyik elképzelt tesztjének pár lépését mutatjuk be, minta jelleggel. Különösen kezdő tesztelők számára nagyon fontos, hogy legyen egy kézzelfogható minta, ami vezérfonal a munkájukhoz. A tesztesetek neve utaljon a teszt tárgyára! Ha komplexebb tesztekről van szó, érdemes a teszteket nevükben is csoportosítani, mint például: Navigáció, Beolvasás, Nyomtatás stb. Példa: Teszteset_Navigáció_#1 Maguk a tesztlépések több logikai egységből is állhatnak. A Leírás tartalmazza a tesztelő által végrehajtandó tevékenységet. Használunk egy Megjegyzés oszlopot is, mely elsősorban a tesztelő számára szolgál hasznos kiegészítő információkkal a tesztvégrehajtáshoz. Az elvárt eredmény leírásának félreérthetetlenül egyértelműen tartalmaznia kell annak a leírását, hogy mikor számít sikeresnek a teszt.Példánkban számozva szerepel mindegyik tesztlépés. 
Teszteredmények dokumentálásaA teszteredmények dokumentálását mindig adott projektre kell szabni. Éppen ezért csak gondolatébresztőként mutatunk be egy egyszerű táblázatos szerkezetet, mely jó kiindulási alap lehet teszteredmények rögzítésére. Ha e célból rendelkezésre áll külön szoftver, akkor mindenképpen azt kell használni. Egy dolgot nem tehetünk meg: a teszteredményeket nem dokumentálni. 
8. Minőségbiztosítási receptekEgy jó tesztelő nem csupán végrehajtja a rá bízott feladatokat, hanem képes javaslatokat is tenni a szoftver minőségének növelésére, konkrét folyamatok javítására. Itt elsősorban a minőségbiztosítási folyamatokra kell gondolni. Az alábbiakban összeállítottunk egy javaslat-, vagy sokkal inkább receptcsomagot, melyet számos vállalkozás, cég használhat a tesztelés és a minőségbiztosítás javítására. Minden esetben egy hibás, vagy alacsony hatékonyságú kiindulási helyzetet veszünk alapul, majd javaslatot is megfogalmazunk a helyzet javítására. A leírások között sok tesztelő, esetleg fejlesztő a saját munkahelyén tapasztalható hiányosságokat is találhat. Ez a fejezet bátorítani is kívánja őket abban, hogy javítsanak a munkahelyükön a minőségbiztosítási folyamatokon. A tesztelés hiányaElsősorban kisebb cégeknél közkedvelt megoldás fejlesztőkre bízni a tesztelést. Ez a gyakorlat a fejlesztők idejét pazarolja, másrészt pedig igen kis hatékonyságú tesztelést tesz csak lehetővé, részben az időhiány, részben pedig a szakmai képzettség, gyakorlat hiányából fakadóan. Javaslat Lehetőleg minél hamarabb hivatásos, de mindenképpen elfogulatlan, főállású tesztelőket kell alkalmazni. Minél tovább elodázódik ez a döntés, annál költségesebb és lassabb lesz a szoftver minőségét elfogadható szintre hozni. A teszt tervezésének elmaradásaA tesztek tervezésére nincsen idő elkülönítve, a tesztelőknek azonnal el kell kezdeniük az új funkciók tesztelését. Ezt gyakran a tesztelők már meglévő tapasztalatával indokolják. Javaslat A tervezési fázis nem csupán az ismert funkciók teszteléséről, hanem a nem-funkcionális és járulékos előfeltételekről, kockázatokról is lerántja a leplet. A teszteket a fejlesztési munkák megkezdése előtt el kell kezdeni tervezni, a tesztelőket, vagy legalább a tesztmenedzsert be kell vonni a kapcsolódó megbeszélésekbe. Tesztelés és fejlesztés különválasztásaA fejlesztői oldal már létszámában is többségben van. Gyakorta előfordul, hogy a programozók, vagy a fejlesztések vezetője egyik másik tesztnek nagyobb fontosságot tulajdonít, míg mások végrehajtását igyekszik gátolni, esetleg a talált hibák „elkendőzésére” tesz kísérletet. Javaslat A tesztelés a fejlesztés része, de autonóm tevékenység kell, hogy legyen. Mindenféle befolyásolás súlyosan veszélyeztetheti a szoftver minőségét. Ennek a veszélynek az elhárítását legtöbbször a tesztmenedzser hivatott biztosítani. Hiányában a tesztelők igen kiszolgáltatott helyzetbe kerülhetnek. Tesztmenedzsment hiányaAzon cégek, melyek már alkalmaznak tesztelőket, gyakran igyekeznek „házon belül”, szakember nélkül megoldani a tesztelés koordinálását. Nem ritka, hogy egy tapasztalt fejlesztőre bízzák ezt. Ez legjobb esetben is hiányos eredményekhez vezet. Javaslat A tesztelés menedzselt tevékenység kell, hogy legyen. Erre külön tesztmenedzsereket, esetleg ún. SCRUM mastereket alkalmaznak, akik elkötelezettek a tesztelés iránt és tesztelői oldalról közelítenek a projektekhez. Tesztcélok hiányaA tesztelők a feladataikról csak annyi információt kapnak, hogy „tesztelni kell az új verziót”. Javaslat Teljeskörűen egyetlen szoftvert sem lehet soha letesztelni, ezért fontos, hogy a tesztelés célja és tárgya definiálva legyen. Ez ideális esetben írásban is rendelkezésre áll. A tesztcélok meghatározása a tesztmenedzser feladata. Dedikált tesztkörnyezet hiányaA kizárólag tesztre használt számítógépek gondolatát tapasztalatlan vezetők általában kétkedéssel kezelik. Nem ritkák az ehhez hasonló reakciók: „Miért nem jó egy kiszuperált gép?”, „Használjátok az egyik fejlesztői számítógépet, ha éppen nincsen használatban!”, „Ez túl drága mulatság nekünk, nem engedhetjük meg magunknak!” Javaslat Egy tesztelésre nem felkészített számítógép nem megfelelő teszteredményeket fog szolgáltatni. Valójában egy rossz tesztkörnyezet az igazi pénzpocsékolás, ami ráadásul be is csap mindenkit, így egy dedikált tesztgéppel valójában pénzt lehet spórolni. Tesztadatok hiányaTapasztalt tesztelők sokat tudnának mesélni arról, hogy mennyire komolytalanul kezelik egyik-másik fejlesztési projektben a tesztadatokat, és ez mekkora többletmunkát tud utólag eredményezni. Némi fanyar iróniával úgy is mondhatnánk, hogy a tesztelőknek gyakran bűvészmutatványokat kell bemutatniuk: szinte a semmiből valamilyen eredményt kell kicsiholniuk. Javaslat Egy lelkiismeretes tesztelőt már azzal is boldoggá lehet tenni, ha pontosan leírják, hogy milyen adatokat kell használnia. Még jobb, ha minták is rendelkezésre állnak. A legjobb azonban, ha mindig naprakész elvárások és leírások állnak rendelkezésre a tesztadatokat illetően. Ezek elkészítésében természetesen a tesztelők maguk is nagy örömmel részt vesznek. Dokumentáció hiányaA fejlesztett szoftver kézikönyve, specifikációja hiányos, elavult, vagy ad absurdum nem létezik. Javaslat A tesztelés végrehajtása során egy elvárt eredményt hasonlítunk össze aktuális eredményekkel. Fontos tehát, hogy egyértelműen rögzítsük az elvárt eredményeket (hogy hogyan kell működnie az alkalmazásnak), különben a tesztelés nem több puszta erőlködésnél és színjátéknál. Fejlesztések dokumentálásának hiányaA fejlesztések tervei és megvalósításai időben nem visszakereshetőek. Javaslat Egy-egy hiba keresésénél rendkívül fontossá válhat annak ismerete, hogy egy adott fejlesztés mikor került bele a szoftverbe. Eztvalamilyen formában, visszakereshető módon dokumentálni kell. Manuális és funkcionális tesztelés különválasztásaA manuális tesztelést és az automata tesztek karbantartását, végrehajtását ugyanarra a tesztelőre bízzák. Javaslat A manuális tesztelés közvetlen céljai és feltételei merőben különbözőek lehetnek és mindkettő teljes embert kíván. A legrosszabb kombináció az 50-50 százalékos felosztás, ebben az esetben ugyanis a tesztelőnek esélye sincsen arra, hogy bármelyik területtel mélyebben foglalkozzon. Tesztesetek nem megfelelő dokumentálásaJelentős költségmegtakarító tényezőnek tartják a tesztelést támogató szoftverek „kispórolását” a projektekből. A különböző táblázatkezelők csak kisszámú feladat dokumentálására alkalmazhatóak és korlátozottan. Mégis gyakran használják komplex feladatok, például tesztesetek tárolására is. Ez a gyakorlatban nem ér többet, mint egy halom papírfecni, amire félmondatokat firkálunk. Javaslat A tesztesetek létrehozására célszoftvert kell alkalmazni mindentesztelés esetén. Ez az újrafelhasználást és a kiértékeléseket is lehetővé teszi, ill. elősegíti a hosszú távú, „újrahasznosítható” tesztelési munkát. Teszteredmények dokumentálásának hiányaA tesztek eredményeiről gyakorta legfeljebb e-maileket szokás írni, de ezek további rögzítése elmarad. Sok információ „szájhagyomány” útján terjed. Javaslat A tesztek eredményei nem csak egy adott fejlesztési periódusban értékesek, hanem később is. Számos esetben a teszteredmények csak hosszabb távon mutatnak ki bizonyos hibákat a szoftverekben. Teszteredmények kiértékelése hiányzikA teszteredmények kiértékelésével nem foglalkozik senki, összefüggéseket senki nem von le, emiatt (is) gyakori, hogy bizonyos típusú hibák mindig visszatérnek a szoftver tesztelése során. Javaslat A tesztek eredményei összefüggnek, számszerűsíthetőek és időben ábrázolva további, mélyebb következtetések levonására adnak lehetőséget. Minden lehetséges eszközzel, de inkább célszoftverrel érdemes elemezni a teszteredményeket. Egy ilyen rendszer többnyire megegyezik a tesztek rögzítésére használt szoftverrel. Feladatok delegálásaHirtelen felmerülő határidők, ismeretlen funkciók tesztelésének azonnali igénye, „tegnapi” határidős feladatok felbukkanása. Javaslat Nemcsak a tesztelés során, hanem általában is megvan a módja a feladatok kiosztásának. A vezetőknek tisztában kell lenniük legalább 5 alapfeltétellel, melyek a számonkérés alapját képezhetik. Ezek: ki, mit, milyen eszközökkel, hogyan, milyen határidővel végez el. Számonkérésnek csak abban az esetben van értelme, ha ezeket a kérdéseket tisztáztuk és megbeszéltük a feladat végrehajtásával megbízott munkatárssal, esetünkben a tesztelőkkel. A tesztelő felelőssége, hogy megfelelő információk hiányában ne vállaljon el hiányosan megfogalmazott feladatokat. 9. Tesztelői kisszótárAgilis fejlesztésAgilis fejlesztés: a projektben dolgozó csapatok együttműködésére építő fejlesztési módszertan. Átadási tesztÁtadási teszt: általában ügyféloldalon végrehajtott teszt, melynek célja, hogy az ügyfél megbizonyosodjon arról, hogy azt kapja, amit megrendelt. DebuggingDebugging: a szoftver felügyelt módban történő futtatása, részletes elemzési lehetőségekkel. Fejlesztőeszközökben elérhető lehetőség. Dinamikus tesztelés (dynamic testing)Dinamikus tesztelés (dynamic testing): a szoftver futásidejű tesztelése. Elfogadási tesztElfogadási teszt: a szoftver átadását megelőző átfogó teszt, melynek során a szoftverrel szemben támasztott kritériumok kerülnek tesztelésre. Elvárt eredmények (expected result)Elvárt eredmények (expected result): a teszt sikeres kimenetelének leírása. Fehér doboz tesztelés (white box testing)Fehér doboz tesztelés (white box testing): a szoftver kódját figyelembe vevő, vagy egyenesen azt célzó tesztelés. Fekete doboz tesztelés (black box testing)Fekete doboz tesztelés (black box testing): egy adott szoftver belsőszerkezetét nem figyelembe vevő tesztelés. Felfedezéses tesztelés (exploratory testing)Felfedezéses tesztelés (exploratory testing): ad hoc jellegű, nem folyamat központú tesztelés. Felhasználási folyamatleírások (user story)Felhasználási folyamatleírások (user story): egy adott üzleti folyamat felhasználói szemszögből történő leírása. Funkcionális specifikációFunkcionális specifikáció: a szoftver egyes funkcióinak részletes leírása, beleértve a működés feltételeinek megadását is. Funkcionális tesztFunkcionális teszt: egyes szoftverfunkciók működésének tesztje. KomponenstesztKomponensteszt: szoftverkomponensek tesztje. Hiba (bug, fault, defect)Hiba (bug, fault, defect): konkrét, kimutatható hibajelenség. Hiba érvényességeHiba érvényessége: a hiba mivoltának meghatározása. Hibajelentés (bug report)Hibajelentés (bug report): teszt során talált hiba technikai leírása. Hibás működés (failure)Hibás működés (failure): hibajelenségből eredő, az elvárttól eltérőműködés. Hibázás (error, mistake)Hibázás (error, mistake): a hiba létrehozásának folyamata. HotfixHotfix: gyorsjavítás száma. Integrációs tesztIntegrációs teszt: szoftverkomponensek együttműködésének tesztje. Kick-off meetingKick-off meeting: projektindításkor megtartott megbeszélés. MinőségMinőség: egy adott (szoftver) termék tulajdonságainak összessége, mely azt jellemzi. MinőségbiztosításMinőségbiztosítás (quality assurance, QA): olyan tevékenységek összessége, melyek a fejlesztett szoftver tervezett minőségét hivatottak biztosítani. Negatív tesztesetNegatív teszteset (negative test case): szoftverek hibakezelésének, hibatűrésének tesztelésére összeállított teszteset. Nem-funkcionális tesztNem-funkcionális teszt: a szoftver járulékos, nem egyes funkciókhoz köthető tulajdonságainak tesztje. PrioritásPrioritás: fontosági sorrend. PriorizálásPriorizálás: fontossági sorrend felállítása. Product owner („terméktulajdonos”)Product owner („terméktulajdonos”): vezető a projektben, aki egy adott megoldás (program modul, vagy teljes szoftver) kifejlesztéséért felel. ProjektkoordinátorProjektkoordinátor: a projekt résztvevői közötti információ áramlásért, a felmerülő általános igények jelzéséért felelős személy. ProjektmenedzserProjektmenedzser: a projekt sikeres lebonyolításáért felelős vezető. Regressziós tesztRegressziós teszt: annak tesztje, hogy új funkció nem okozott-e hibát már korábban is elérhető funkciókban. ReleaseRelease: szoftverkiadás száma. RendszertesztRendszerteszt: egy rendszer (hardver és szoftver) teljes funkcionalitását célzó teszt. ReviewReview: felülvizsgálat, melynek során programozók, vagy tesztelők egymás munkáját ellenőrzik. SCRUMSCRUM: az agilis módszertanokhoz tartozó fejlesztési mód, mely erősen csapatközpontú.Scrum MasterScrum master: a SCRUM csapat működéséért felelő szervező, aki a fejlesztők és a tesztelők munkáját is támogatja. SprintSprint: fejlesztési ciklus a SCRUM-on belül, tipikusan egy hetet ölel fel. Statikus tesztelés (static testing):Statikus tesztelés (static testing): olyan tesztelési technika, melynek során a tesztelt szoftver nem fut (forráskód-elemzés, dokumentáció ellenőrzése stb.). Strukturális tesztStrukturális teszt: lásd fehérdoboz tesztelés. MinőségMinőség: egy adott (szoftver) termék tulajdonságainak összessége, mely azt jellemzi. SúlyosságSúlyosság: hiba kihatásának jelzésére szolgál. Szürke-doboz tesztelés (grey box testing)Szürke-doboz tesztelés (grey box testing): egy adott szoftver belsőszerkezetét figyelembe vevő tesztelés. Teszt dizájn (test design)Teszt dizájn (test design): konkrét teszt, teszteset előkészítését célzó tevékenység. Teszteset (test case)Teszteset (test case): logikailag összetartozó tesztlépések összessége, egysége. Tesztfuttatás (test execution)Tesztfuttatás (test execution): logikailag összetartozó tesztlépések végrehajtása. Tesztkiértékelés (test evaluationTesztkiértékelés (test evaluation): teszt végeredményének meghatározása. Tesztkoordinátor, tesztvezetőTesztkoordinátor, tesztvezető: a tesztelés napi szintű, operatív végrehajtásáért felelős személy, egy, esetleg több csapaton belül. Tesztkörnyezet (test environment)Tesztkörnyezet (test environment): valós rendszert szimuláló infrastruktúra. Tesztlépés (test step)Tesztlépés (test step): a teszteset elemi végrehajtási egysége, mely tartalmazza az elvárt eredmény leírását is. TesztmenedzserTesztmenedzser: a tesztelés zökkenőmentes lebonyolításáért felelős vezető.TesztriportTesztriport (test report): teszt kimenetlének összefoglalása, számszerűsített adatokkal alátámasztva. Teszt forgatókönyv (test scenario)Teszt forgatókönyv (test scenario): üzleti követelményekből levezetett összefoglaló leírások. Teszt státusz (test status)Teszt státusz (test status): a teszt végkimenetelének, eredményének megnevezése. TesztstratégiaTesztstratégia: a teszt céljait, módszereit, feltételeit, a felelősségköröket meghatározó dokumentum. Teszt terv (test plan)Teszt terv (test plan): teszt végrehajtásának írásos vázlata. Teszt-vezérelt fejlesztésTeszt-vezérelt fejlesztés: olyan programozási módszer, melynek során a programkódot eleve a későbbi tesztelhetőség szempontjait figyelembe véve készítik el. Teszt záró riport (test exit report)Teszt záró riport (test exit report): általában több teszt eredményeit összefoglaló és kiértékelő, nagyobb lélegzetvételű dokumentum. Üzleti elemző (business analyst)Üzleti elemző (business analyst): üzleti folyamatok technikai szintre történő lefordítását segítő szakember. Üzleti folyamat (business process)Üzleti folyamat (business process): egy adott üzleti cél eléréséhez szükséges tevékenységsorozat. Üzleti követelmény (business requirement)Üzleti követelmény (business requirement): üzleti folyamatok alkalmazásához, végrehajtásához szükséges előfeltételek. V-modellV-modell: fejlesztési modell, melynek egyes fázisai lineárisan, szekvenciálisan követik egymást. VerzióVerzió: egy szoftver időben különböző változatainak jelzésére szolgáló szám. Vezető fejlesztőVezető fejlesztő: egy csapaton, vagy projekten belül a legtöbb tapasztalattal rendelkező programozó. Vezető tesztelő (test lead)Vezető tesztelő (test lead): nagy tesztelői- és projekt tapasztalattal rendelkező tesztelő, aki aktívan részt vesz a mindenkori tesztstratégia kialakításában és a tesztek levezénylésében. Tesztelés különböző platformokonTesztelés asztali számítógépekenAz asztali számítógépes környezetben végzett tesztelés a leginkább elterjedt, mivel ilyen számítógépekkel nagyon sokan rendelkeznek otthon is. Ezek készség szintű használata, ismerete ezért nem okoz gondot egy átlagos tesztelőnek sem. A kihívást itt elsősorban a fejlesztéshez használt technológiák dömpingjében történő eligazodás jelenti. A trend egyértelműen a böngészős alkalmazások terjedése, a lokálisan telepített, ún. standalone alkalmazások száma csökken bár eltűnni nem fognak, hanem egyre inkább speciálisabb területeken használják őket. |